Aided Parametric Estimating ( CAPE ) to Process Maturity Levels

A current thrust in software engineering economics involves process evaluation and follow-up recommendations for improvements that speed delivery time, improve quality, and save cost; in other words, reengineering the process. A basis for many organizational evaluations is the Software Engineering Institute (SEI) Capability Maturity Model (CMM). This model defines five levels of increasing process maturity and the characteristics of each. Achieving higher levels of maturity involves improvements in the specific areas of Software Project Planning, Software Product Tracking and Oversight, and Integrated Software Management. Improving these processes requires core measurements to establish performance baselines, benchmark improvement, and predict future organization performance. Computer Aided Parametric Estimating (CAPE) can play a major contributing role in software performance and capability measurement. Reaching higher levels of maturity also involves a cost investment that must be weighed by organizational management for benefit. Key to the process improvement decision is the expected return from the investment How much time will be saved? How much product quality improvement will there be? What are the savings in resources? SEI CMM Computer software is a relatively new technology. Despite the explosion of digital data processing in all facets of everyday life, the first electronic computer (the ENIAC) was built only 46 years ago. When compared to older mechanical and electrical device technology, it is fair to say that we are still in the toddler years of s o h a r e engineering maturity. Many promises from the 70s and 80s regarding a revolution in development methods have been unfulfilled. Recognizing that the technological maturation process was to be more evolutionary, the Software Engineering Institute (SEX) at Carnegie Mellon University in Pittsburgh, PA began to establish a process maturity framework in late 1986. With assistance from the Mitre Corporation, SEI established the framework goal to be assisting organizations in improving their software process. The fundamental problem identified is characteristic of most new technological advances the inability to manage the process of creating specific applications with the technology. In the 80's, the environment was chaotic and undisciplined. Tools were few and not integrated. For the most part, no organization infrastructure existed to guard against the pitfalls of over cost, behind schedule delivery of poor quality software. In fact, the term "pre-planned product improvement" became commonplace in scheduling for software product delivery. Still, there were enough examples of software products producing excellent results, even within undisciplined organizations, to offer clues about general technology improvement. Though success can result from dumb luck, more often it results from disciplined methods that are consistently applied and continuously improved. This was the common thread among the successful software developments observed. What was missing was organization and widespread adoption of the effective discipline. Discipline of methodology was, and to a large extent still is, an individual issue. Relying on certain individuals for success provides no foundation for widespread quality and productivity improvements of an organization or the technology as a whole. Clearly, solving the problems of 1 software would require definition and building of the infrastructure to engineer and manage the new technology effectively. The concept of maturity implies adoption and use of a disciplined process, while immaturity 1 implies an ad-hoc approach. The domain of software people covered by the SEI use of maturity i 9 organizational as opposed to individual. So, while there may be examples of individual software maturity, there are few that encompass entire organizations. Without organizational maturity, there can be little to further technological maturity. So, the idea is to spread successful practices 1 from individuals through policies, standards, and structures that produce an evolving organization 1 maturity. This is known as institutionalizing the software process. I The Capability Maturity Model (CMM) is intended to provide organizations with guidance needed1 to gain control of the software development and maintenance processes in order to evolve a culture1 of sofhyare engineering excellence. By focusing on a few of the more critical issues related to 1 software quality and process improvement, organizations can aggressively movetowgds greater maturiry. The roadmap for progression alongthepath ofgreater maturity is the framework of the1 CMM. Its roots trace back to the 1930s quality control theory promulgated at AT&T Bell Labs 1 and later developed hrther by others, most notably W. Edwards Deming. 1 The 5 Levels of Software Process Maturitv I Continuous process improvement is based on many small, evolutionary steps rather than one or two revolutionary innovations. The CMM h e w o r k identifies five successive steps and the 1 properties of each in the maturation process. Each level is a well-defined plateau on the path 1 toward maturation. Achieving each level requires that an organization demonstrate the ability to meet the process requirements associated with that level co&stently. Notice that the framework does not attempt to quantifL the quality or resource requirement goals of a level. This is due to the attention of the model to capability (Capability Maturity Model) and not performance. Sofhvare process maturity deals with potential for growth in capability or the expected results from use of a process. Performance at any given time on any given project may be reflective of greater or less maturity than that for which an organization is capable. Over time, the organization's performance will mirror its capability. The next figure @age 3) illustrates the five SEI maturity levels and the orderly progression from I one kvef to the next The frgure is followed by a biiefchaFracterization of each level.I Each maturity level is associated with a more controlled and stable ability to predict organizational 1 performance in developing andfor maintaining a software project. Variations fiom expectation are 1 mnfined to a narrow range. The illustration on page 4 depicts the capability norms for Levels 1 1 and 5. Notice three things fiom this picture: 1. The expected range of outcomes is much narrower for Level 5. 2. Because of the strength of discipline employed at Level 5, variations from target are truly random. However, at Level 1, variations are more likely to be increases in target resources and decreases to target quality due to the greater likelihood of chaos. 3. There is the possibility (however small) that a Level 1 organization can deliver the same or similar quality software with the same expenditure of resources as a Level 5 Adapting Computed Aided Parametric Estimating (CAPE) to Process Maturity Levels Bruce E. Fad Page 2 1 organization. If this occurs, it will most likely be the result of select individuals at Level 1 performing like most individuals at Level 5. The 5 Software Process Maturity Levels Continuously Process . . . . . . . . . . . . . . . . . . . . . . . . .